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A  graphics  user  interface  called  GLAD  (Graphics  LAnguage  for  Database)  is 
proposed  as  a  unified  interface  method  for  a  user  interaction  with  a  database.  GLAD 
provides  a  coherent  interaction  method  for  all  three  user  interactions  with  a  database: 
data  definition  interaction,  data  manipulation  interaction,  and  program  development 
interaction.  In  this  paper,  the  features  of  data  manipulation  interaction  of  GLAD  are 
described.  Specifically,  the  method  of  representing  and  manipulating 
generalized/specialized  objects  and  recursively  related  objects  is  presented,  and  the 
notion  of  program  box  which  is  used  for  specifying  a  complex  query  is  introduced. 


1.    Introduction 

To  attain  a  wider  acceptance  and  usage,  a  database  management  system  must 
accommodate  more  different  types  of  users.  These  users  range  from  very  sophisticated 
users,  such  as  database  administrators  and  system  designers,  to  naive  users,  such  as 
secretaries,  clerks,  and  other  non-technical  users  of  database.  In  this  paper,  we  describe 
a  graphical  user  interface  that  accommodates  both  sophisticated  and  naive  users. 

Users  of  a  database  management  system  interact  with  a  database  in  three  different 

ways.  The  first  is  the  creation  of  database  via  a  data  definition  language.  The  second 
is  the  accessing  (i.e.  retrieval  and  update  of  information)  of  database  via  a  data 
manipulation  language.  And  the  last  is  the  development  of  application  programs  via  an 
embedded  host  language  (i.e.  a  regular  programming  language  embedded  with  a  data 
manipulation  language).  We  call  these  three  different  user  interactions,  respectively, 
data  definition  interaction,  data  manipulation  interaction  and  program  development 
interaction.  In  a  relational  database  management  system  INGRES,  for  example,  a  query 
language  called  QUEL  is  provided  for  data  manipulation  and  definition,  and  an 
embedded  query  language  called  EQUEL/C  is  provided  for  developing  application 
programs.  To  utilize  these  specialized  languages  successfully,  users  must  be  well  versed 
in  computer  programming  concepts. 

In  a  traditional  data  processing  application  of  database  management  system,  naive 
users'  interation  with  a  database  is  usually  limited  to  the  accessing  of  database;  thus,  the 
previoulsy  proposed  "user-friendly"  interfaces  are  concentrated  on  the  data  manipulation 
interaction.  A  "canned"  menu-driven  query  system,  where  each  choice  in  the  menu  is  a 
specific  query  such  as  "list  all  customers  with  outstanding  balance,"  is  a  common  user 
interface  employed  for   accessing   a  database.  Problems  with  the  canned  menu-driven 


'By  creation  of  database,  we  mean  the  definition  of  database  schema  and  not  the  actual  loading  of  data  into  the  database. 


query  system  are  that  it  can  only  be  used  by  naive  users  (it  is  too  tedious  for 
sophisticated  users)  and  that  it  has  very  limited  querying  capability  (users  can  only  ask 
what  the  menu  provides). 

New  proposals  for  a  better  data  manipulation  interface  can  be  classified  into  three 
different  approaches:  a  natural  language  interface,  a  modified  query  language  interface, 
and  a  graphics  interface.  A  natural  language  interface  [BOGU84,  CODD74,  HEND77, 
WALTS78]  is  primarily  developed  for  naive  users,  and  therefore,  it  may  not  be  suitable 
for  more  sophisticated  users.  Pros  and  cons  for  using  a  natural  language  interface  as  a 
database  access  method  are  presented  in  [PETR76].  The  second  approach,  a  modified 
query  language  interface  [KORT84,  MACG85],  employs  a  similar  syntax  as  a  regular 
query  language  but  with  more  simplified  syntax  and  enriched  semantic.  It  is  intended 
for  both  sophisticated  and  naive  users.  The  third  approach,  a  graphics  interface 
[HERO80,  LARS84,  MCD074,  STON82,  SUGI84,  WONG82,  WU85,  ZL0077],  uses 
graphic  objects  as  a  tool  for  accessing  database.  This  approach  is  also  intended  for  both 
types  of  users. 

As  a  better  interface  for  program  development  interaction,  so  called  Fourth 
Generation  Languages  are  proposed.  These  commercial  products  are  advertised  as  so 
easy  to  use  that  non-technical  managers  can  develop  their  own  application  programs  by 
themselves.  Although  we  feel  that  these  Fourth  Generation  Languages  are  in  general 
easier  to  use  than  embedded  host  languages,  we  view  these  advertisers"  claims  more  of  a 
sales  gimmick.  A  much  better  approach  called  fill- in- the- form  programming  for  an 
application  program  development  is  reported  in  [ROWE85].  With  this  approach,  a  user 
develops  a  complete  application  by  interactively  composing  a  collection  of  frames,  which 
consists  of  forms  to  display/enter  data  and  a  menu  of  operations. 


Expressing  the  conceptual  schema  of  database,  once  it  is  designed,  in  a  data 
definition  language  is  the  easiest  of  all  three  interactions.  And  therefore,  not  much  effort 
has  been  done  to  build  a  good  interface  for  data  definition  interaction.  However,  we  feel 
that  just  providing  a  syntactic  mean  to  express  the  conceptual  schema  of  database  is  not 
enough.  A  good  user  interface  for  data  definition  interaction,  we  believe,  should  aid 
users  in  the  design  process.  GAMBIT  [BRAG84]  is  one  such  interactive  user  interface: 
however,  it  is  intended  primarily  for  database  adm   listrators  and  not  for  naive  users. 

A  database  management  system  must  provide  a  good  user  interface  for  all  three 
interactions  to  make  the  system  easy  to  use  and  learn  for  both  sophisticated  and  naive 
users.  We  should  note  that  simply  combining  some  of  the  aforementioned  proposals  is 
not  acceptable,  because  users  must  learn  three  different  interaction  methods  to  utilize  the 
database  management  system.  We  believe  that  a  single,  coherent  interation  method 
must  be  provided  for  all  three  interactions  in  order  to  gain  an  acceptance  and  to  increase 
a  usage  of  database  management  system  by  a  wider  audience. 

We  believe  a  graphical  interface  has  the  best  potential  in  developing  such  single, 
coherent  interaction  method  applicable  to  all  three  interactions,  and  thus,  we  propose  a 
graphical  interface  GLAD  (Graphics  LAnguage  for  Database).  GLAD  has  two  major 
advantages.  First,  it  provides  a  single  environment  where  different  techniques  proposed 
for  different  purposes  can  be  integrated.  Specifically,  in  GLAD,  techniques  proposed  in 
QBE.  GUIDE,  TIMBER,  G-WHIZ,  etc  are  all  integrated  into  a  single  working  whole. 
Rather  than  re-inventing  a  wheel,  we  provide  a  framework  where  different,  previously 
proposed  techniques  are  integrated  into  one  unit,  which  we  believe  is  a  much  better 
approach.  Second,  GLAD  maintains  a  high  degree  of  data  independence.  GLAD  is  not 
tied  to  any  specific  implementation  and  therefore,  it  can  serve  as  a  front-end  to  relational 
or  network  DBMS.     And  it  is  also  possible  to  have  a  specialized  implementation  for 


GLAD.  Since  GLAD  can  be  attached  to  relational  or  network  DBMS,  many  existing 
databases  can  become  available  (by  having  GLAD  front-end)  to  all  users  who  learn 
GLAD. 

A  major  contribution  of  GLAD  to  a  user  interface  research  is  its  single,  unified 
interface  method  for  all  three  interactions.  By  providing  a  coherent  interface  method, 
GLAD  achieves  a  high  degree  of  ease  of  learning  and  using.  To  our  knowledge,  there  is 
no  other  proposal  that  addresses  the  issue  of  a  unified  interface  method  for  all  three  user 
interactions.  Specific  contributions  of  this  paper  are  the  presentation  of  simple  graphical 
representations  for  different  types  of  generalized/specialized  and  recursively  related 
objects  and  the  introduction  of  program  box  concept.  GLAD  is  the  first  graphical 
interface  that  can  represent  these  objects  and  allow  users  to  manipulate  them  in  a  simple 
fashion. 

The  paper  is  organized  as  follows.  The  characteristics  of  a  good  user  interface  for 
data  manipulation  and  an  overall  description  of  a  data  manipulation  interaction  via 
GLAD  are  given  in  the  next  section.  Section  3  illustrates  a  data  manipulation  interaction 
via  GLAD  by  going  through  a  sample  session.  Section  4  and  5  discuss  the  representation 
and  manipulation  of  generalized/specialized  objects  and  recursively  related  objects, 
respectively.  Section  6  introduces  the  notion  of  program  box  which  is  used  as  an  aid  in 
formulating  complex  queries.    And  finally,  Section  7  concludes  the  paper. 

2.    Data  Manipulation  Via  GLAD 

A  good  user  interface  for  data  manipulation  interaction  capable  of  supporting  both 
sophisticated  and  naive  users  must  have  the  following  characteristics: 

(1)     It  must  be  descriptive.    It  must  show  what  kinds  of  data  (employee,  department, 
equipment,  etc)  are  stored  in  the  database  and  how  they  are  related  to  each  other. 


We  call  such  representation  of  data  and  their  rela  ionships  database  schema.    Also, 
it   should  provide  a  help    (i.e.   describe   more   about   the  database)   if  requested   by 


users. 


(2)  It  must  be  powerful.  Users  must  be  able  to  express  a  complex  query  by  using  it. 

(3)  It  must  be  easy  to  learn.  Naive  and  uninitiated  users  should  be  able  to  master  the 
interaction  method  quickly  and  start  accessing  the  database  with  a  short  learning 
period. 

(4)  It  must  be  easy  to  use.  It  must  be  easy  to  use  so  users  rarely  make  erroneous 
queries  and  can  formulate  complex  queries  simply  and  quickly.  Also,  users  should 
be  able  to  specify  a  query  in  different  ways;  they  should  not  be  forced  to  remember 
a  particular  way  to  pose  a  query. 

Query    languages    of   currently    available    database    management    systems    lack    in    all 
characteristics  but  (2). 

A  review  of  previously  proposed  graphics  user  interfaces  [HERO80,  LARS84, 
MCD074,  STON82,  SUGI84,  WONG82,  ZL0077]  by  using  the  criteria  listed  above  as  a 
yardstick  is  given  in  [WU85].  We  shall  simply  note  here  that  none  of  them  attains  all 
four  characteristics  satisfactorily.  A  graphics  user  interface  for  data  manipulation 
interaction  that  we  describe  here  can  be  viewed  as  a  synthesis  of  previoulsy  proposed 
graphics  user  interfaces.  By  incorporating  their  good  features  and  eliminating  their  weak 
points,  we  believe  that  GLAD  has  achieved  a  higher  degree  of  descriptivenes,  ease  of 
learning  and  using,  and  power. 

For  ease  of  reference,  we  shall  call  the  part  of  GLAD  that  deals  with  the  data 
manipulation  interaction  GLAD  DMC  (Data  Manipulation  Component).  In  the 
following,  we  describe  the  salient  features  of  GLAD  DMC.  These  features  are 
categorized  into  four  characteristics  mentioned  above. 


2.1.    GLAD  DMC  is  descriptive 

GLAD  DMC  displays  a  diagram  of  the  database  schema.  This  GLAD  diagram  is 
semantically  rich,  which  means  that  it  is  capable  of  capturing  a  real  world  semantics 
(how  the  information  stored  in  the  database  are  related  to  each  other)  naturally  and 
precisely.  Conventional  data  models,  such  as  relational,  network,  and  hierarchical  data 
models  are  semantically  poor  compared  to  new  data  models,  such  as  SDM,  TAXIS,  E/R, 
etc.  A  GLAD  diagram  is  applicable  to  many  semantic  data  models  ,  because  it  provides 
an  elegant  diagrammatic  representation  of  real  world  abstraction  concepts  those 
semantic  data  models  employ.  The  abstraction  concepts  we  are  dealing  with  here  are: 
aggregation,  generalization,  and  classification.  In  the  following,  we  discuss  each  of  them 
and  show  how  each  is  represented  in  a  GLAD  diagram. 

Aggregation: 

An  object3  is  an  aggregation  of  (sub)objects.  For  example,  a  student  object  could 
be  an  aggregation  of  name,  address,  ssno.  gpa,  and  dept  (sub)objects.  An  aggregate 
object  is  represented  as  a  rectangle  in  a  GLAD  diagram,  see  Figure  2.1a.  A  user  can  see 
the  sub(objects)  of  an  aggregate  object  by  expanding  it,  see  Figure  2.1b.  Notice  that  the 
dept  object  is  not  shown  in  Figure  2.1b  because  it  is  not  an  atomic  object.  Only  first 
four  objects  are  atomic;  that  is,  they  are  an  aggregation  of  exactly  one  system-defined  or 
a  user-defined  base  object  (string,  number,  enumeration,  subrange  and  boolean).  Since 
the  dept  object  is  an  non-atomic  aggregate  object,  say,  an  aggregation  of  name,  set  of 
students,  set  of  courses,  and  school,  it  was  not  shown  in  Figure  2.1b.  Each  non-atomic 
object  in  the  database  is  displayed4  .  and  an  association  between  objects  is  represented  as 
a  line  between  these  objects,  see  Figure  2.1c.    Notice  that  the  dept  object  is  shown  as  a 


'Although  we  feel  that  a  GLAD  diagram  is  applicable  to  almost  all  semantic  models,  there  may  be  some  data  models  that  we 
are  unaware  of  or  do  not  fully  understand.    Therefore,  we  shall  refrain  ourselves  from  making  such  claim  until  further  study  is  made. 

3We  do  not  define  the  term  object  here;  we  intuitively  view  an  object  as  a  "thing"  (both  tangible  and  intangible)  that  exists. 

A  database  designer  can  modify  it  so  a  non-atomic  object  is  not  displayed. 
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separate  rectangle.    Notice  also  that  an  association  is  not  labelled.    We  discuss  the  issue 
of  labelling  an  association  in  Section  5. 

Generalization: 

Individual  objects,  such  as  faculty,  secretary,  and  technician,  can  be  grouped 
together  to  form  a  generalized  object,  say,  employee.  Faculty,  secretary,  and  technician 
objects  are  called  specialized  objects  of  employee.  Generalization  abstraction  can  be 
characterized  as  an  IS-A  relationship  (faculty  IS- A  emloyee,  etc.). 

A  generalized  object  is  represented  in  a  GLAD  diagram  as  a  nested  rectangle,  see 
Figure  2.2a.  A  user  can  expand  the  nested  rectangle  and  view  the  specialized  objects,  see 
Figure  2.2b.  These  specialized  objects  can  themselves  be  the  generalized  objects  of  yet 
further  specialized  objects.  A  faculty  object,  for  example,  can  be  a  generalized  object  of 
full,  associate,  and  assistant  professors.  Graphical  representations  of  different  types  of 
generalized/specialized  objects  are  given  in  the  next  section. 

We  have  already  mentioned  in  the  previous  subsection  that  an  association  between 
objects  is  represented  as  a  solid  line  in  a  GLAD  diagram.  When  one  or  both  of  the 
associated  objects  are  specialized  objects,  a  dotted  line  is  used.  Figure  2.3  shows  how  the 
dotted  lines  are  used  in  a  GLAD  diagram. 

An  aggregate  object  can  have  a  disjunctive  association,  which  means  that  an  object 
can  have  either  one  (sub)object  or  another.  We  use  a  small  circle  to  show  a  disjunctive 
association.  Figure  2.4  says  that  an  equipment  can  belong  either  to  a  department  or  to  a 
school. 

Classification: 

Each  data  item  stored  in  a  database  is  information  aborit  some  object.  For 
example,  data  item  [bruce  Springsteen,  n.  j.,  123-45-6789.  3.2,  music]  is  an  information 


about   student,  and  it   is   classified  as  a  student  object.     We  call  each  data  item  of  an 
object  a  member  of  that  object. 

2.2.    GLAD  DMC  is  easy  to  learn 

The  number  of  concepts  a  user  has  to  learn  in  order  to  access  a  database  via  GLAD 
DMC  is  few,  and  the  interaction  method  is  consistent  throughout  the  interface.  Circle, 
regular  and  nested  rectangles  ,  and  solid  and  dotted  lines  are  the  only  concepts  that  a 
user  need  learn  to  understand  the  GLAD  diagrams.  Morever,  the  HELP  and 
DESCRIBE  commands  are  always  available  to  a  user.  The  interaction  method  is  also 
very  straightforward.  A  user  will  select  the  operation  by  first  moving  the  mouse  to  the 
desired  operation  and  then  clicking  the  mouse  button.  A  user  can  also  select  the 
operation  by  pressing  the  corresponding  function  key  or  by  typing  the  operation  name. 
After  selecting  a  desired  operation,  a  user  must  select  an  argument (s)  (by  moving  the 
mouse  to  the  desired  argument  and  clicking  the  mouse  button)  that  the  chosen  operation 
will  be  executed  on.  For  example,  a  user  will  first  select  an  operation  LIST  MEMBER 
and  then  select  an  argument  subject  to  list  all  subject  matters  stored  in  the  database. 
The  result  is  shown  in  Figure  2.5.  The  complete  result  cannot  fit  into  a  window  and 
therefore,  only  seven  subject  matters  are  displayed  in  the  window.  A  user  can  browse 
the  data  by  moving  the  small  square  vertically  or  by  positioning  the  mouse  at  the  arrow 
and  pressing  the  mouse  button.  In  GLAD  DMC.  a  user  may  reverse  the  sequence  of 
interaction,  that  is,  a  user  selects  argument(s)  first  and  then  selects  the  operation.  This 
flexibility  helps  users  learn  the  interaction  method  easily. 

For  more  complex  retrieval  operations,  a  QBE-like  interface  is  used.  The  notable 
difference  between  ours  and  the  original  QBE  is  that  ours  does  not  need  the  use  of 
variables  for  queries  involving  more  than  one  objects   (relations  in  the  original  QBE). 


The  third  type,  repeated  rectangle,  is  used  to  represent  a  recursively  related  ojbects. 
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The  results  of  various  psychological  studies  that  demonstrate  QBE's  ease  of  learning  and 
using  are  well  documented  in  [THOM75].  By  avoiding  the  use  of  variables  and  by 
displaying  the  database  schema,  we  believe  ours  is  easier  to  learn  and  use. 

2.3.  GLAD  DMC  is  powerful 

GLAD  DMC's  power  to  express  a  complex  query  is  a  direct  consequence  of  adopting 
a  QBE-like  interface  for  specifying  a  query.  QBE  is  relationally  complete,  which 
guarantees  that  it  is  capable  of  expressing  any  query  that  can  be  expressed  in  relational 
algrebra  or  relational  calculus.  This  relational  completeness  is  a  general  criteria  used  to 
prove  the  expressive  power  of  a  query  language.  Because  GLAD  DMC  has  inherited  all 
the  querying  capabilities  of  QBE,  GLAD  DMC  is  also  relationally  complete. 

2.4.  GLAD  DMC  is  easy  to  use 

GLAD  DMC's  flexibility  of  allowing  a  user  to  formulate  a  query  in  different  ways 
and  in  incremental,  piece-by-piece  fashion  makes  it  easy  to  use.  By  allowing  a  user  to 
pose  a  query  in  different  ways,  it  appeals  to  the  wider  range  of  users.  If  there  is  only  one 
way  to  pose  a  query,  it  probably  would  not  appeal  to  all  users,  because  the  allowed  query 
specification  may  be  too  difficult  to  naive  users  or  may  be  too  cumbersome  for 
sophisticated  users.  Each  user  has  his  own  preferred  way  of  specifying  a  query,  and  the 
user  interface  should  allow  different  ways  of  specifying  the  same  query  as  much  as 
possible. 

Incremental  query  specification  would  also  appeal  to  the  wide  range  of  users. 
Rather  than  writing  the  specification  for  a  complete  query  and  executing  it,  GLAD  DMC 
users  can  retrieve  the  result  of  the  complete  query  in  a  piece-by-piece,  incremental 
manner.  A  user  formulate  the  complete  query  by  first  (mentally)  decomposing  the  query 
into  smaller  subqueries.    After  specifying  each  subquery  correctly,  he  combines  them  to 
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retrieve  the  result  for  the  complete  query.  In  this  way.  a  user  can  formulate  a  complex 
query  in  an  expedient  manner  with  very  few  errors.  A  sample  session  in  the  following 
section  will  illustrate  the  sequence  of  incremental  querying. 

The  ability  to  browse  the  result  also  improves  the  ease  of  use.  The  result  may 
actually  contain  more  than  what  a  user  really  wanted.  Instead  of  reformulating  the 
query,  the  user  can  simply  browse  through  the  result  and  get  information.  If  the  user 
wants  to  save  the  desired  result,  then  he  can  delete  the  unwanted  records  while  browsing 
through  the  retrieved  result. 


3.    Sample  Session 

We  now  illustrate  the  features  of  GLAD  by  going  through  a  sample  session. 
Specifically,  we  show  how  the  user  can  retrieve  the  answer  to  "List  all  classes  that  deal 
with  the  subject  of  probability  and  that  are  taken  this  quarter  (Fall  '85)  by  the  students 
who  are  majoring  in  Computer  Science  and  whose  gpa's  are  better  than  3.5." 

Figure  3.1   is  the  GLAD  diagram  for  a  university  database  schema.     Figure  3.2a 

shows  the  hierarchical  structure  of  GLAD  commands.  Associated  with  each  command  is 
a  positive  integer  which  corresponds  to  the  function  key  number.  A  user  can  select  the 
command  either  by  using  the  mouse,  by  pressing  the  corresponding  function  key,  or  by 
typing  the  operation  name.  The  top  level  menu  is  shown  in  Figure  3.2b.  The  menu  will 
be  placed  on  one  part  of  a  screen.' 

To  get  the  answer  to  the  query,  the  user  enters  the  QUERY  mode  by  selecting  the 
QUERY  command  from  the  second  level  menu.  The  third  level  menu  is  now  displayed 
on  the  screen.    He  decomposes  the  query  into  two  part:  one  that  lists  all  courses  that  deal 


6Not  all  commands  are  shown  here  and  some  of  the  commands  shown  here  will  not  be  discussed  in  this  paper. 

7Exact  position  is  not  determined  yet.    We  anticipate  to  position  it  either  on  the  top  or  on  the  right  hand  side  of  a  screen. 
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with  probability  and  another  that  lists  all  classes  taken  in  the  Fall  55  quarter  by  the 
Computer  Science  students  whose  gpa's  are  better  than  3.5.8  The  user  SPECIFYs  the 
subject,  see  Figure  3.3.  the  course,  see  Figure  3.4,  and  the  line  connecting  the  two  to  get 
the  result  of  the  first  subquery.  An  alternative  method,  where  the  user  specifies  every 
condition  within  the  course  object,  is  shown  in  Figure  3.5.  The  subject  column  is 
appended  to  the  course  object  when  the  user  selects  the  SHOW  CONNECTED  OBJECT 
command. 

To  actually  get(retrieve)  this  intermediate  result,  the  user  issues  the  CREATE 
RESULT  command,  see  Figure  3.6.  Notice  that  the  result  icon  and  the  subject  and 
course  objects  are  shaded  identically.  He  can  now  request  SHOW  RESULT  to  verify 
that  the  intermediate  result  is  what  he  wants.  Similar  to  the  LIST  MEMBER 
command,  the  SHOW  RESULT  command  will  allow  users  to  browse  the  intermediate 
result.  The  SHOW  RESULT  command  gives  an  immediate  feedback  to  users  enabling 
the  early  detection  of  erroneous  query  specification.  As  users  become  more  proficient, 
they  can  bypass  the  SHOW  RESULT  command.  Having  these  two  separate  commands, 
GLAD  can  help  naive  users  (if  asked)  by  providing  an  immediate  feedback,  but  it  will 
not  force  such  help  on  sophisticated  users.  By  going  through  a  similar  query 
specification,  the  user  creates  the  result  for  the  second  subquery,  see  Figure  3.7. 

When  a  user  formulates  many  subqueries.  he  may  forget  what  the  (sub) results  were 
about.    He  may  prompt  GLAD  to  describe  them.    For  example,  the  description  of 

contains  class  information  where 
dept.name  =  'Computer  Science'  and 
student. gpa  >  3.5 

.will  appear  under  result  2  if  the  user  requests  to  DESCRIBE  result  2.  A  user  may 
change  the  environment  by  executing  the  SETUP  command  so  the  description  of  a  result 
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is  displayed  automatically. 

Finally,  the  user  retrieves  the  complete  answer  by  combining  two  (sub) results  by 
executing  the  COMBINE  RESULTS  command,  see  Figure  3.8.  and  selecting  the 
association  between  them.  If  the  user  desires  to  have  a  permanent  copy  of  the  answer, 
he  can  save  the  answer  by  selecting  SAVE  RESULT. 

4.    Representation  and  Manipulation  of  Generalized/ Specialized  Objects 

In  this  section,  we  describe  the  graphical  representations  for  different  types  of 
generalized/specialized  objects.  We  start  with  some  definitions.  Let  G  be  a  generalized 
object   and  T(G)    =   {   SVS2,   ■  ••  ,Sn  }  where  each  S,   =  {   St,St,    ■  ■  •   ,5,     }.     5,  is  called 

1  2  tn 

category  and  St  specialized  object  of  G  in  category  Sr    For  example,  we  may  have 

r(employee)  =  {  {engineering,  business},  {faculty,  secretary,  technician},  {male,  female}  } 

for  an  employee  object. 

In  [WU85],  the  following  assumptions,  or  conditions,  are  made: 

(a)  0  ^  n  ^  1    (note:  n  =  0  means  G  is  not  a  generalized  object) 

(b)  5,  p|  5, .  =  <t>  for  j  ^  k,  1  ^  i  ^  n,    1  ^  j,k  ^  m 

m 

(c)  u5. ■  =  G   for  1  ^  i  ^  n. 

;  =  i 

The  above  assumptions  are  made  to  simplify  the  preliminary  design  of  GLAD  DMC. 
The  first  assumption  says  that  an  object  can  have  at  most  one  category.  The  second  and 
third  assumptions  together  say  that  when  an  object  has  a  category,  a  member  of  the 
(generalized)    object    must    be    a    member    of    exactly    one    specialized    object.      Above 


8He  may,  of  course,  decompose  in  other  ways. 
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r  I  employee)  violates  condition  (a).  Suppose  an  employee  can  be  a  faculty  and  a 
technician  at  the  same  time,  then  it  violates  condition  (b).  And  suppose  there  is  an 
employee  who  is  not  a  faculty,  secretary,  or  technician  (say.  he  is  an  administrator),  then 
it  violates  condition  (c). 

In  the  following,  we  show  how  these  assumptions  can  be  removed  and  yet  have 
elegant  and  effective  graphical  representations  of  generalized/specialized  objects. 

4.1.    Specialization  in  more  than  one  category 

One  possible  way  to  graphically  represent  T  (employee)  given  above  is  shown  in 
Figure  4.1.  This  method  of  showing  all  specialized  objects  in  every  category  is  not 
acceptable  in  the  following  accounts:  (1)  it  cannot  be  extended  nicely  to  handle  the 
situation  where  the  other  two  conditions  are  removed,  (2)  it  contradicts  our  general 
philosophy  of  good  user  interface,  which  is  to  show  the  minimal  amount  of  information 
(i.  e.  highest  level  of  abstraction)  initially  and  to  show  the  detail  only  when  requested  by 
users,  (3)  it  becomes  unwieldy  when  the  number  of  categories  is  large,  and  (4)  it  does  not 
lend  itself  to  a  easy  formulation  of  query  which  involves  more  than  one  category. 

The  method  we  adopt  here  is  based  on  the  fact  that  specialized  objects  inherit  all 
attributes  of  the  generalized  object.  When  a  user  request  to  expand  the  generalized 
object  G,  which  has  more  than  one  category,  GLAD  DMC  will  prompt  the  user  to  select 
which  category  to  expand.  When  a  user  issue  the  EXPAND  operation  on  the  employee 
object  described  above,  a  pop-up  menu  will  appear  on  the  screen  as  shown  in  Figure  4.2. 
A  user  has  an  option  of  expanding  the  employee  object  in  any  one  of  the  categories 
listed.  If  a  user  selects  the  job  category,  then  the  screen  will  show  the  employee  object 
expanded  along  the  job  category,  see  Figure  4.3.  Since  the  specialized  objects  inherit 
attributes  from  the  generalized  object,  faculty,  secretary,  and  technician  objects  all  have 
two  categories,  i.e.  sex  and  school  categories.     So,  if  a  user  requests  to  EXPAND  the 
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secretary  object  in  Figure  4.3.  then  the  situation  shown  in  Figure  4.4  will  result.  Notice 
that  with  this  method,  users  have  a  wide  variety  of  expanding  a  generalized  object:  they 
expand  the  object  in  a  way  that  fits  most  naturally  to  a  query  that  they  are  formulating. 

4.2.  Specialized  objects  are  not  disjoint 

When  specialized  objects  are  not  disjoint,  then  there  is  a  member  i  of  G  such  that 
i  c  S-  for  more  than  one  i.  In  other  words,  specialized  objects  overlap  (if  we  view  object 
as  a  set).  Figure  4.5  depicts  the  situation  where  there  exists  a  member  x  of  G  such  that 
xeSl  and  xtS2.  Notice  that  the  LIST  MEMBER  operation  executed  on  St  and  on  the 
overlapped  region  of  5,  and  52  will  result  differently.  Examples  in  Figure  4.6  show  the 
versatility  of  this  approach. 

4.3.  Union  of  specialized  objects  is  not  equal  to  a  generalized  object 

m 

If  (j  5-  ^  £•  then  there  is  a  member  x  of  G  such  that  x  is  not  a  member  of  any  of  St . 

This  situation  is  graphically  depicted  by  creating  a  unnamed  rectangle,  see  Figure  4.7. 
This  unnamed  rectangle  clearly  shows  that  there  is  a  member  who  does  not  belong  to 
any  specialized  object.  This  approach  fits  perfectly  with  other  solutions  given  in  two 
previous  subsections  and  the  overall  design  of  GLAD  DMC. 

5.    Representation  and  Manipulation  of  Recursively  Related  Objects 

We  call  an  object  recursively  related  if  there  is  an  association  between  the  members 
of  the  same  object,  and  such  association  is  called  recursive.  For  example,  there  may  be 
associations  such  as  "married"  and  "parent-of"  between  the  members  of  the  people 
object.  Recursively  related  objects  are  graphically  represented  as  a  repeated  rectangle, 
see  Figure  5.1.    Notice  that  in  Figure  5.1.  there  are  two  associations  on  the  people  object, 
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and  they  are  not  labelled.  Associations  are  not  labelled  in  a  GLAD  diagram  even  if 
there  are  more  than  one  association  between  the  same  objects.  Then,  how  does  a  user 
know  which  association  is  which? 

Automatic  labelling  of  associations  will  cause  the  cluttering  of  a  screen  and 
therefore,  we  decided  not  to  label  them.9  Normally  there  is  only  one  association  between 
objects,  and  once  a  user  asks  GLAD  to  EXPAND  it  (or  DESCRIBE  it  if  more  detailed 
explanation  is  desired),  he  can  usually  remember  its  meaning  for  the  duration  of  a  on- 
line session.  However,  if  a  user  is  a  very  forgetful  person,  he  may  end  up  asking  GLAD 
repeatedly  for  the  expansion  of  the  same  association.  Also,  if  there  are  more  than  one 
association  between  objects,  it  may  be  difficult  to  keep  track  of  which  association  is 
which.  To  aid  users  in  these  situations,  GLAD  DMC  allows  users  to  label  associations 
(in  fact,  they  can  label  almost  anything  in  a  GLAD  diagram).  So  there  are  two  levels  of 
flexibility.  First,  a  user  has  a  choice  of  labelling  an  association  or  not.  And  second,  he 
can  label  it  any  way  he  wants  to  once  he  decides  to  label  it.  He  can  use  a  word(s)  that 
helps  him  remember  the  semantic  of  an  association  best.  This'  may  be  viewed  as  a 
another  form  of  semantic  relativism. 

The  method  for  the  manipulation  of  recursively  related  objects  in  GLAD  is 
modelled  after  G-WHIZ  [HEIL85].  We  modified  their  method  so  that  it  integrates  nicely 
into  the  GLAD  framework.  Recursive  query  is  formulated  in  GLAD  DMC  by  specifying 
the  beginning  (root)  member  of  the  hierarchy,  the  direction  and  depth  of  the  traversal. 
and  the  regular  attribute  qualifications.  For  example,  to  list  the  grandfathers  of 
'Walter',  a  user  puts  the  specification  as  shown  in  Figure  5.2a  and  then  selects  the 
appropriate  recursive  association  (in  this  case,  it  is  parent-of).  The  term  BU3  in  Figure 
5.2a  stands  for  Begin  hierarchy  Upward  for  S  levels.  The  downward  traversal  for  n  levels 


9By  default,  there  is  no  label;  but  users  can  change  this  default  so  a  label  always  appears  on  a  screen. 
''Expanding  a  recursively  related  object  from  one  starting  point  will  end  up  in  a  hierarchy  of  members. 
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is  expressed  as  BDd.  The  BU  operation  is  unique  to  GLAD:  in  G-WHIZ.  only  BD  is 
available.  The  specification  "Walter"  under  the  name  column  states  that  the  traversal 
begins  from  'Walter*.  The  END  specification  under  the  sex  column  states  that  the 
condition  "=male"  applies  to  the  members  in  the  last  (i.e.  end)  level  of  the  hierarchy. 
The  END  specification  under  the  people  column  states  that  only  the  members  in  the  last 
level  of  the  hierarchy  are  to  be  retrieved.  The  other  two  options  are  BEG  and  ALL. 
These  options  are  used  to  specify  the  stated  conditions  are  applied  to  the  members  of 
which  levels  of  a  hierarchy.  The  specification  in  Figure  5.2b  retrieves  all  grandfathers  of 
the  person  named  Tat"  who  is  a  female.  When  the  desgination  of  which  members  that 
the  stated  conditions  are  applied  to  becomes  more  complex,  then  the  PATH  option  is 
used.  The  value  of  PATH  designates  the  specific  member  of  a  hierarchy.  For  example, 
PATH  =  2.1  of  designates  the  first  member  at  the  level  3  who  is  a  parent  of  the  second 
member  at  the  level  2.  If  the  hierarchy  is  an  ordered  tree,  and  the  first  member  is  father, 
while  the  second  is  mother,  then  the  member  at  PATH  =  2.1  is  Walter's  maternal 
grandfather. 

6.    Program  Box 

It  is  helpful  to  have  program  control  structures  to  formulate  a  complex  query, 
because  it  may  not  be  possible  to  specify  some  complex  queries  just  by  the  features  of 
the  GLAD  DMC  discussed  so  far.  To  provide  a  further  assistance  to  users  in  formulating 
a  complex  query,  GLAD  supports  the  feature  called  program  box.  It  is  an  extension  of 
the  condition  box  employed  in  the  QBE  system.  A  program  box  is  a  window  on  a 
screen,  where  a  complex  query  is  formulated  by  combining  the  control  structures  and  the 
results  obtained  through  the  normal  GLAD  DMC  interaction. 

We  use  the  query  "list  all  companies  located  in  San  Diego  where  three  generations 
of  a  family  all  work  for"  as  an  elucidative  example  of  using  a  program  box.    The  result  1 
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and  result.2  boxes  in  Figure  6.1  are.  respectively,  for  a  father  and  grandfather  of 
person,  where  person  is  the  variable  used  in  the  query  formulation.  The  query 
formulations  for  these  results  are  specified  similarly  as  those  described  in  the  previous 
section,  except  that  here  the  variable  is  used.  The  user  attaches  more  meaningful  names 
fat  her  Of  and  grandfather  Of  to  the  result  1  and  result  2  boxes  by  executing  the 
LABEL  command.  The  program  box  is  invoked  by  the  PROGRAM  BOX  command, 
and  the  query  is  specified  as  shown  in  Figure  6.2.  A  program  box  will  be  placed  either 
on  top  of  GLAD  diagram  as  a  separate  window  or  on  the  side  of  GLAD  diagram;  if 
possible,  the  system  will  always  put  the  program  box  on  the  side  of  GLAD  diagram  for 
better  visibility.  Notice  that  the  functional  notation  similar  to  DAPLEX  [SHIP81]  is 
used.  Also,  notice  that  the  list  of  control  structures  is  provided.11  Instead  of  actually 
typing  in  the  whole  program,  a  user  can  also  create  it  by  copying  the  result  boxes  and 
objects  into  the  program  box. 

Here  we  treated  a  program  box  strictly  as  an  added  database  accessing  tool.  But  it 
is  also  a  tool  for  program  development  interaction,  because  a  user  can  create  an 
application  program  by  using  a  program  box.  So  there  is  actually  no  clear  distinction 
between  program  development  interaction  and  data  manipulation  interaction  in  GLAD, 
which  is  exactly  what  we  have  hoped  for.  In  other  words,  the  GLAD  DMC  with  a 
program  box  capability  serves  the  dual  role  of  query  language  and  embedded  host 
language.  Data  definition  interaction  via  GLAD,  moreover,  is  essentially  a  creation  of 
database  schema  by  arranging  graphical  objects  such  as  rectangles,  lines,  and  circle  and 
specifying  their  associations,  attributes,  and  integrity  contraints.  Therefore,  in  GLAD, 
all  three  user  interactions  have  a  consistent,  unified  interface  method. 


'Not  all  choices  are  shown  in  the  figure. 
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7.    Conclusion 

We  have  presented  in  this  paper  a  motivation  behind  a  unified  interface  method  for 
interactions  with  a  database.  And  we  have  proposed  a  graphics  user  interface  GLAD  as 
an  ideal  candidate  for  such  unified  database  interface  method.  We  believe  the  GLAD's 
coherent  interface  method  with  its  high  degree  of  descriptiveness,  ease  of  learning  and 
using,  and  power  will  appeal  to  both  sophisticated  and  naive  users. 

The  result  we  have  presented  here  is  an  outgrowth  of  the  work  reported  in  [WU85]. 
We  originally  viewed  a  graphical  interface  is  suitable  only  for  data  manipulation.  But 
we  soon  realized,  after  we  reported  our  preliminary  design  of  a  graphical  interface  for 
accessing  a  database  in  [WU85].  that  our  approach  can  be  extended  to  the  other  two 
user  interactions.  Our  work  on  data  definition  and  program  development  interactions 
will  be  reported  in  forthcoming  papers. 

We  have  already  initiated  an  implementation  effort  using  the  ISI  workstations  with 
graphics  terminals.  We  anticipate  that  the  kernel  portion  of  GLAD  DMC  with  a 
program  box  capability  as  described  here  will  be  implemented  within  the  next  six 
months.  Our  implementation  goal  is  to  make  it  portable  so  that  it  can  be  adapted  as  a 
front-end  for  any  DBMS  without  much  conversion  effort. 

Since  there  are  too  many  areas  of  possible  future  research  for  GLAD,  we  shall 
mention  here  only  some  of  those  which  are  directly  related  to  the  subjects  discussed  in 
this  paper.  First  is  the  representation  and  manipulation  of  an  object  which  is  a 
specialization  of  more  than  one  generalized  object.  A  work-study  student  object,  for 
example,  is  a  specialized  object  of  both  employee  and  student  objects.  We  would  like  to 
add  an  elegant  graphical  representation  of  an  inter-specialized  object  to  a  GLAD 
diagram.  Second  is  the  representation  and  manipulation  of  a  generalized/specialized 
association    such    as    a    parent-of   association    which    can    be    viewed    as    a    generalized 
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association  of  father-of  and  mother-of  associations.  Just  as  we  have  a 
generalized/specialized  object,  it  may  be  superior  (as  far  as  data  modelling  is  concerned) 
to  have  a  generalized/specialized  association.  And  last  is  the  graphical,  syntax-directed 
program  box.  Instead  of  a  user  invoking  a  program  box  and  typing  in  a  program,  we 
would  like  to  have  a  user  creates  a  program  by  utilizing  a  graphical,  syntax-directed 
editor.  With  this  editor,  icons  for  the  control  structures  are  provided  and  a  user  creates 
a  program  by  arranging  these  icons  in  a  program  box.  We  believe  a  technique  similar  to 
the  one  reported  in  [GLIN84]  can  be  employed  for  this  purpose. 
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